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LEGACY CORBA NAME SPACE INTEGRATION USING WEB APPLICATION 

SERVERS 



BACKGROUND OF THE INVENTION 

5 

1. Technical Field: 

The present invention relates to an improved data 
processing system. In particular, the present invention 
relates to a method, apparatus, and computer instructions 
10 to bind object references from a remote name space into a 
local name space using a Web application. 



2. Description of Related Art: 

Common Object Request Broker Architecture (CORBA) is 

15 an architecture that enables objects to communicate with 
one another regardless of the programming language or 
operating system of the objects. An object is a 
self-contained software module or piece of a program. 
CORBA is a standard for communicating between distributed 

20 objects. CORBA provides a means to execute programs 
written in different programming languages located on 
various platforms within a network. Using the standard 
protocol Internet Inter-ORB Protocol (HOP), a 
CORBA- based program from any vendor, on almost any 

25 computer, operation system, programming language, and 

network, can interoperate with a CORBA-based program from 
the same or another vendor, on almost any other computer, 
operating system, programming language, and network. 
CORBA was developed by an industry consortium, which is 

30. named the Object Management Group (OMG) . 

There are several implementations of CORBA, the most 
widely used being IBM's System Object Model (SOM) and 
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Distributed System Object Model (DSOM) architectures. 
Netscape also uses CORBA in the Netscape ONE (Open 
Network Environment) platform. Two competing models are 
Microsoft's Component Object Models (COM) and Distributed 
5 Component Object Model (DOOM) and Sun Microsystems' 
Remote Method Invocation (RMI) . 

CORBA was designed to allow interoperation of 
distributed systems. However, until the CORBA 
Interoperable Name Space (INS) becomes widely available, 

10 there is no standard means of contacting a remote name 

space to obtain an object reference. An object reference 
unambiguously identifies an object and is never reused to 
identify another object. Vendors are implementing the 
CORBA INS as a means of providing a standardized 

15 mechanism for accessing a remote name space, but this 

will not work for the large set of applications existing 
today, which do not support the CORBA INS. 

At runtime, a CORBA client makes requests to remote 
CORBA objects through an Object Request Broker (ORB) . 

20 The ORB handles the details involved in routing a request 
from client to object, and routing the response to its 
destination. Many ORBs store the information about an 
object in vendor-specific internal structures. There is 
a standard form, called the Interoperable Object 

25 Reference (lOR) that ORBs use to pass object references 
to one another across vendor boundaries. The ORB will 
stringify the reference of an object into a sequence of 
hexadecimal numbers so that the reference is able to pass 
over the network without being translated by any of the 

30 various filters. If a client does not know the servers 
ORB, then the client will not be able to access a remote 
name space on the server. Different vendors do not use 
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the same bootstrap protocol for obtaining a reference to 
the name service and may use different ORBs, thus 
creating problems obtaining lookup or reference to a 
CORBA object. 

Therefore, it would be advantageous to have an 
improved method, apparatus, and computer instructions to 
provide means for accessing the remote name space. 
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SUMMARY OF THE INVENTION 

The present invention provides a method, apparatus, 
and computer implemented instructions for binding object 
5 references from a remote name space into a local name 

space using a Web application. Information is collected 
to generate a request for an object reference. 
Information, such as an application server to use as the 
source, a source name space path, an identification of 

10 destination server, and a destination name space path to 
which the object reference is to be bound, may be used. 
The request is sent using a communications protocol, such 
as hypertext transfer protocol to the application server 
to be used as the source for the object reference. An 

15 object reference is located using the name space The 

object reference may be serialized into a format, such as 
a common object request broker architecture format and 
sent to the destination. The destination will 
unserialize the object reference and perform binding 

20 using the destination name space path. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The novel features believed characteristic of the 
5 invention are set forth in the appended claims. The 

invention itself, however, as well as a preferred mode of 
use, further objectives and advantages thereof, will best 
be understood by reference to the following detailed 
description of an illustrative embodiment when read in 
Q 10 conjunction with the accompanying drawings, wherein: 

41 Figure 1 depicts a pictorial representation of a 

%A network of data processing systems in which the present 

invention may be implemented; 
j5 Figure 2 is a block diagram of a data processing 

^ 15 system that may be implemented as a server in which the 

present invention may be implemented; 
O Figure 3 is a block diagram illustrating a data 

L processing system in which the present invention may be 

P implemented; 

^' 20 Figure 4 is a block diagram of application servers 

in accordance with a preferred embodiment of the present 
invention; 

Figure 5 is block diagram of the name space binder 
Web application in accordance with a preferred embodiment 
25 of the present invention; 

Figure 6 is a flowchart of the general application 
flow in accordance with a preferred embodiment of the 
present invention; 

Figure 7 is a flowchart of the setup of the Web 
30 application in accordance with a preferred embodiment of 
the present invention; 
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Figure 8 is a flowchart of the locate request 
forwarding servlet process in accordance with a preferred 
embodiment of the present invention; 

Figure 9 is a flowchart of the locate object 
reference request process in accordance with a preferred 
embodiment of the present invention; and 

Figure 10 is a flowchart of the bind serialized lOR 
servlet process in accordance with a preferred embodiment 
of the present invention. 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

With reference now to the figures. Figure 1 depicts a 
pictorial representation of a network of data processing 
5 systems in which the present invention may be implemented. 
Network data processing system 100 is a network of 
computers in which the present invention may be 
implemented. Network data processing system 100 contains 
a network 102, which is the medium used to provide 
^ 10 communications links between various devices and computers 

ifl connected together within network data processing system 

100. Network 102 may include connections, such as wire, 
lH wireless communication links, or fiber optic cables. 

^ In the depicted example, server 104 is connected to 

pi 15 network 102 along with storage unit 106. In addition, 

L clients 108, 110, and 112 are connected to network 102. 

0 These clients 108, 110, and 112 may be, for example, 

f"'^ personal computers or network computers. In the depicted 

p example, server 104 provides data, such as boot files, 

^ 20 operating system images, Web pages and applications to 

clients 108-112. Clients 108, 110, and 112 are clients to 
server 104. Network data processing system 100 may 
include additional servers, clients, and other devices not 
shown . 

25 In the depicted example, network data processing 

system 100 is the Internet with network 102 representing a 
worldwide collection of networks and gateways that use the 
TCP/IP suite of protocols to communicate with one another. 
At the heart of the Internet is a backbone of high-speed 

30 data communication lines between major nodes or host 
computers, consisting of thousands of commercial. 
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government, educational and other computer systems that 
route data and messages. Of course, network data 
processing system 100 also may be implemented as a number 
of different types of networks, such as for example, an 
5 intranet, a local area network (LAN), or a wide area 

network (WAN) . Figure 1 is intended as an example, and 
not as an architectural limitation for the present 
invention. 

Referring to Figure 2, a block diagram of a data 

10 processing system that may be implemented as a server, 

such as server 104 in Figure 1, is depicted in accordance 
with a preferred embodiment of the present invention. 
Data processing system 200 may be a symmetric 
multiprocessor (SMP) system including a plurality of 

15 processors 202 and 204 connected to system bus 206. 

Alternatively, a single processor system may be employed. 
Also connected to system bus 206 is memory 
controller/cache 208, which provides an interface to local 
memory 209. I/O bus bridge 210 is connected to system bus 

20 206 and provides an interface to I/O bus 212. Memory 
controller/cache 208 and I/O bus bridge 210 may be 
integrated as depicted. 

Peripheral component interconnect (PCI) bus bridge 
214 connected to I/O bus 212 provides an interface to PCI 

25 local bus 216. A number of modems may be connected to PCI 
local bus 216. Typical PCI bus implementations will 
support four PCI expansion slots or add- in connectors. 
Communications links to clients 108-112 in Figure 1 may be 
provided through modem 218 and network adapter 220 

30 connected to PCI local bus 216 through add-in boards. 
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Additional PCI bus bridges 222 and 224 provide 
interfaces for additional PCI local buses 226 and 228, 
from which additional modems or network adapters may be 
supported. In this manner, data processing system 200 
5 allows connections to multiple network computers. A 

memory-mapped graphics adapter 230 and hard disk 232 may 
also be connected to I/O bus 212 as depicted, either 
directly or indirectly. 

Those of ordinary skill in the art will appreciate 

y 10 that the hardware depicted in Figure 2 may vary. For 

^£1 example, other peripheral devices, such as optical disk 

drives and the like, also may be used in addition to or in 

y place of the hardware depicted. The depicted example is 

not meant to imply architectural limitations with respect 

. 15 to the present invention. 

^ The data processing system depicted in Figure 2 may 

£ be, for example, an IBM e-Server pSeries system, a 

product of International Business Machines Corporation in 
2 Armonk, New York, running the Advanced Interactive 

20 Executive (AIX) operating system or LINUX operating 

system. 

With reference now to Figure 3, a block diagram 
illustrating a data processing system is depicted in which 
the present invention may be implemented. Data processing 
25 system 300 is an example of a client computer. The 

processes of the present invention for identifying Web 
pages may be implemented within a client, such as data 
processing system 300. 
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In this example, data processing system 300 employs a 
peripheral component interconnect (PCI) local bus 
architecture. Although the depicted example employs a PCI 
bus, other bus architectures such as Accelerated Graphics 
5 Port (AGP) and Industry Standard Architecture (ISA) may be 
used. Processor 302 and main memory 304 are connected to 
PCI local bus 306 through PCI bridge 308. PCI bridge 308 
also may include an integrated memory controller and cache 
memory for processor 302. Additional connections to PCI 

10 local bus 306 may be made through direct component 

interconnection or through add-in boards. In the depicted 
example, local area network (LAN) adapter 310, SCSI host 
bus adapter 312, and expansion bus interface 314 are 
connected to PCI local bus 306 by direct component 

15 connection. In contrast, audio adapter 316, graphics 

adapter 318, and audio/video adapter 319 are connected to 
PCI local bus 306 by add- in boards inserted into expansion 
slots. Expansion bus interface 314 provides a connection 
for a keyboard and mouse adapter 320, modem 322, and 

20 additional memory 324. Small computer system interface 

(SCSI) host bus adapter 312 provides a connection for hard 
disk drive 326, tape drive 328, and CD-ROM drive 330. 
Typical PCI local bus implementations will support three 
or four PCI expansion slots or add- in connectors. 

25 An operating system runs on processor 302 and is used 

to coordinate and provide control of various components 
within data processing system 300 in Figure 3. The 
operating system may be a commercially available operating 
system, such as Windows 2000, which is available from 

30 Microsoft Corporation. An object oriented programming 
system such as Java may run in conjunction with the 
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operating system and provide calls to the operating system 
from Java programs or applications executing on data 
processing system 300. ^^Java" is a trademark of Sun 
Microsystems, Inc. Instructions for the operating system, 
5 the object-oriented operating system, and applications or 
programs are located on storage devices, such as hard disk 
drive 326, and may be loaded into main memory 304 for 
execution by processor 302. 

Those of ordinary skill in the art will appreciate 

10 that the hardware in Figure 3 may vary depending on the 
implementation. Other internal hardware or peripheral 
devices, such as flash ROM (or equivalent nonvolatile 
memory) or optical disk drives and the like, may be used 
in addition to or in place of the hardware depicted in 

15 Figure 3. Also, the processes of the present invention 
may be applied to a multiprocessor data processing 
system. 

As another example, data processing system 300 may 
be a stand-alone system configured to be bootable without 

20 relying on some type of network communication interface, 
whether or not data processing system 300 comprises some 
type of network communication interface. As a further 
example, data processing system 300 may be a personal 
digital assistant (PDA) device, which is configured with 

25 ROM and/or flash ROM in order to provide non-volatile 
memory for storing operating system files and/or 
user-generated data. 

The depicted example in Figure 3 and above-described 
examples are not meant to imply architectural 

30 limitations. For example, data processing system 300 

also may be a notebook computer or hand held computer in 
addition to taking the form of a PDA. Data processing 
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yi 



system 300 also may be a kiosk or a Web appliance. 
Next, Figure 4 is a block diagram of application servers 
in accordance with a preferred embodiment of the present 
invention. An application server provides an environment 
5 for execution of web applications and remote objects. 
Web applications contain web components such as web 
pages, servlets and JSPs . A web server provides a means 
for using a web application's components through the use 
of the hypertext transport protocol (HTTP) for 

10 communications. Typically, an object request broker 

(ORB) provides a means for using remote objects such as 
CORBA objects or Enterprise JavaBeans through the use of 
the HOP protocol for communications. Application servers 
typically provide additional services. 

15 One such service is the name service which is used 

for location a remote object by name. Examples of name 
services are the Java naming and directory interface 
(JNDI) and COS Naming for CORBA objects. JNDI is a 
programming interface for connecting Java programs to 

20 naming and directory services. Each name service has a 
particular means for access. For JNDI, an InitialContext 
class name is configured for the desired JNDI 
implementation. A new instance of this class is then 
created which represents the root context of the name 

25 tree. COS Naming has no standard means for access. Each 
vendor implementing COS Naming can choose their own 
mechanism for bootstrapping an initial context 
representing the root of the name tree. Name context 
provide a means of navigating the name tree, looking up 

30 content in the name tree, binding (adding) objects into 
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the name tree with a particular name at a particular 
location, and unbinding (removing) objects from the name 
tree . 

In a preferred embodiment of the present invention 
5 Request application server 410 starts by sending a 

request for an object to remote source application server 
420. Source application server 420 looks up the object 
reference and sends the object reference to destination 
server 430, which binds the object reference into the 
51 10 local name space. An object reference is the information 

# or data needed to identify an object. 

Each application server has a copy of the Web 
application of the present invention installed on it. 
Request application server 410 contains Web application 
15 440 running in Web server 415. Source application server 
420 contains Web application 450 running in Web server 
425. Destination server 430 contains Web application 460 
running in Web server 435. In this example, each 
application server also has an ORB. The application 
20 servers communicate using the HTTP protocol. Request 
application server 410 uses Web server 415 to 
communicate with Web server 425 on source application 
server 420. Source application server 420 uses Web 
server 425 to communicate with Web server 435 on 
25 destination application server 430. This mechanism 

bypasses the problematic use of non-standard name space 
bootstrap over HOP by the ORBs for obtaining remote 
references. The Web application, in the source and 
destination application servers, use the ORB to obtain a 
30 name service reference, which is a specific and well 
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known type of CORBA object reference. The name service 
reference is used to obtain or bind the desired object 
reference. 

Figure 5 is block diagram of the Name Space Binder 
5 Web application in accordance with a preferred embodiment 
of the present invention. Client 510 executes a Java 
Server Page (JSP) form, such as JSP form 520, on a 
request application server, such as request application 
server 530. A JSP form is an HTML page with embedded 

10 Java source code that is executed in the Web server or 
application server. Additionally, the request 
application server may be the source application server 
540, destination application server 550, or any other 
application server that has the application installed on 

15 it. JSP form 520 captures the binding information, such 
as the application server URL to use as the source, the 
source name space path, the URL for the destination 
application server, and the destination name space path 
to bind the object reference. Other information that may 

20 be captured could include the ORB host and port location 
if it is different from the application server host, Java 
initial context class name, and ORB class name. However, 
much of this information is constant and could be part of 
the configuration of the application rather than 

25 prompting a user for it. In general, the information 
that a user is prompted for are the two application 
server URLs and two name space paths . 

Request forwarding servlet 560 is invoked in 
response to the user pressing a submit button on the JSP 

30 form. The request forwarding servlet parses the JSP form 
POST request and sends an HTTP redirect to the source 
application server. The HTTP POST request is used to 
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transfer form data from a web client to the server. In 
this case, the POST request contains data for an 
obtaining a reference to an object. The object may be for 
example, a shopping cart for purchases or account number 
5 when accessing a bank account. 

Next, locate object reference servlet 570 looks up 
the object reference on the source application server, 
such as source application server 540, using source name 
space database 575. This database includes data, such as 

10 a name or group of names defined using a naming 

convention. Although in this example a database is used 
for the source name space, other mechanisms may be used 
depending on the particular implementation. The name 
space store is transparent to the application which is 

15 using the name space. When the POST request is forwarded 
to the locate object reference servlet, the servlet 
retrieves the requested object reference using JNDI 
lookup techniques appropriate for that server. The 
servlet creates an instance of an initial context object. 

20 This object implements a naming context interface and 
represents the root of a naming system name tree. The 
POST request data includes the source name space path. 
The servlet uses the initial context object to perform a 
lookup operation using the source name space path. 

25 Depending on the particular server, the process or lookup 
techniques used by locate object reference servlet 570 
may differ. 

The locate object reference servlet then converts 
the object reference into a serialized lOR using the 
30 orb.object_to_string() method. This method is one that 
is available in CORBA. This serialized lOR is then 
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attached to the HTTP POST request and forwarded on to a 
binder servlet using an HTTP redirect to the destination 
server. 

In response to receiving the HTTP POST request, 
5 binder servlet 580 converts the serialized lOR back into 
an object reference by using the orb. string_to_object () 
method, available in CORBA, and then binds the object 
reference into the destination name space, such as 
destination name space 585, using techniques appropriate 
i:J3 10 for the destination application server, such as 

destination application server 550. Binding refers to 
yi the way in which an existing object in one system can be 

^ located by clients in another system and associated with 

itl an appropriate view. In other words, binding causes the 

If^ 15 object reference to be linked to the source application 

p server. Binding is similar to storing information in a 

database. The object that is bound in the name space is 
p given a name. Usually it is of a hierarchical form such 

M^^ that the name space forms a tree of names of objects. 

20 Binding places the object reference into the name space 
such that a lookup of that name at a later point in time 
would retrieve the object reference. 

For example, in the present invention, the servlet 
creates a new initial context instance. If the 
25 destination name space path is complex, intermediate name 
contexts from the root of the tree to the desired leaf 
location are created, if necessary. Then a bind (or 
rebind) operation is performed to bind the object 
reference to a particular named location in the 
30 destination name space. 

In this example, the object reference is looked up 
by locate object reference servlet 570 using JNDI lookup 
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techniques. The object reference is then converted into 
a serialized lOR CORBA format and sent to the destination 
server, such as destination application server 550. At 
the destination server, the serialized lOR is converted 
5 back into an object reference and binding is performed 
using the techniques implemented in the destination 
server. 

Both context and non- context object references can 
be bound in this fashion. The advantage of using the 
10 mechanism is that the mechanism gets around the need to 
deal with proprietary bootstrapping mechanisms for 
obtaining a reference to a remote name space. The 
mechanism of the present invention allows binding remote 
references and federating name spaces without having to 
15 transport serialized lORs between application servers by 
hand. It is easy to bind any combination of application 
servers that have the application installed. 

Figure 6 is a flowchart of the general application 
flow in accordance with a preferred embodiment of the 
20 present invention. The request application server, such 
as request application server 410 in Figure 4, collects 
source and destination information, such as the URL and 
object name from the source and destination servers (step 
610) . The request application server forwards all 
25 information to the source application server, such as 
source application server 420 in Figure 4, using a 
request forwarding servlet (step 620) . The source 
application server looks up the object reference in the 
source name space using a locate object reference servlet 
30 (step 630) . The source application server converts the 
object into a serialized lOR using the 

orb.object_to_string() method from CORBA (step 640). The 
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source application server then forwards the destination 
information and serialized lOR to the destination 
application server (step 650) . The destination 
application server, such as destination application 
5 server 430 in Figure 4, converts the serialized lOR to 
the object reference using the orb,string_to__object () 
method from CORBA (step 660) . The destination 
application server binds the object reference into the 
destination name space using the destination information 
10 and binding techniques appropriate for that server (step 
670) . 

Figure 7 is a flowchart of the setup for the present 
invention in accordance with a preferred embodiment of 
the present invention. The application for the present 

15 invention is deployed on the source application server 

(step 710) , The application for the present invention is 
deployed on the destination application server (step 
720) . A determination is made as to whether the request 
application server is the same as either the source or 

20 destination application servers (step 730) . If the 
request application server is the same as either the 
source or destination application servers, the process 
terminates thereafter. If the request application server 
is not the same as either the source or destination 

25 application servers, the application for the present 

invention is deployed on the request application server 
(step 740) with the process terminating thereafter. 

Figure 8 is a flowchart of the locate request 
forwarding servlet process in accordance with a preferred 

30 embodiment of the present invention. The process 
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illustrated in Figure 8 may be implemented in a request 
forwarding servlet, such as request forwarding servlet 
560 in Figure 5. 

Binding request information, collected from the JSP 
5 form such as JSP form 520 in Figure 5, is received by the 
servlet (step 810) . Next, the URL of the source 
application is retrieved (step 820) . The URL of the 
destination application server is also retrieved (step 
830) . Next, the source name of object reference to bind 
10 is retrieved (step 840) . The destination name of the 

object to bind also is retrieved (step 850) . The request 
^ is then forwarded to the source application server to 

obtain a serialized lOR of the object reference (step 
860) with the process terminating thereafter. 
15 Figure 9 is a flowchart of the locate object 

reference request process in accordance with a preferred 
embodiment of the present invention. The process 
illustrated in Figure 9 may be implemented in a locate 
object reference servlet, such as request locate object 
20 reference servlet 570 in Figure 5. 

The object reference is looked up using the JNDI 
name on the source application server (step 910) . The 
object reference from the source application server is 
converted to a serialized lOR (step 920) . The serialized 
25 lOR is attached to a request (step 930) . The request is 
forwarded to the binder servlet on the destination 
application server (step 940) with the process 
terminating thereafter. 

Next, Figure 10 is a flowchart of the bind 
30 serialized lOR servlet process in accordance with a 
preferred embodiment of the present invention. The 
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process illustrated in Figure 10 may be implemented in a 
binder servlet, such as binder servlet 580 in Figure 5. 

A request is received from the source application 
server to bind the serialized lOR (step 1010) . The 
5 serialized lOR is converted to the object reference (step 
102 0) . The object reference from the source application 
server is bound into the local name space on the 
destination application (step 1030) with the process 
terminating thereafter. This enables the destination 

10 application server to access the object on the source 
application server. At this point the object reference 
for the object on the source application server can be 
accessed in the destination application server by 
performing a local name space lookup. 

15 Therefore, the present invention provides an 

improved method, apparatus, and computer implemented 
instructions for accessing a remote name space. The 
present invention can be implemented by the large set of 
applications existing today that do not support the CORBA 

20 INS as a means to contact remote name spaces to obtain an 
object reference. It also eliminates problems obtaining 
lookup or reference to an object due to incompatibility 
of different protocols and vendor ORBs . 

It is important to note that while the present 

25 invention has been described in the context of a fully 
functioning data processing system, those of ordinary 
skill in the art will appreciate that the processes of 
the present invention are capable of being distributed in 
the form of a computer readable medium of instructions 

30 and a variety of forms and that the present invention 
applies equally regardless of the particular type of 
signal bearing media actually used to carry out the 
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distribution. Examples of computer readable media 
include recordable -type media, such as a floppy disk, a 
hard disk drive, a RAM, CD-ROMs, DVD-ROMs, and 
transmission-type media, such as digital and analog 
communications links, wired or wireless communications 
links using transmission forms, such as, for example, 
radio frequency and light wave transmissions. The 
computer readable media may take the form of coded 
formats that are decoded for actual use in a particular 
data processing system. 

The description of the present invention has been 
presented for purposes of illustration and description, 
and is not intended to be exhaustive or limited to the 
invention in the form disclosed. Many modifications and 
variations will be apparent to those of ordinary skill in 
the art . The embodiment was chosen and described in 
order to best explain the principles of the invention, 
the practical application, and to enable others of 
ordinary skill in the art to understand the invention for 
various embodiments with various modifications as are 
suited to the particular use contemplated. 



